So the general thought behind this is to force a human to look at the results of a decode to determine if it's properly been decoded, thereby (1) making "casual" decoding impossible (as it takes more than computer cycles; (2) making even dedicated decoding difficult, as if there are 15,000 possible passwords, that's 15,000 things that someone has to plod through, and (3) as a bonus, providing a certain amount of ambiguity even if one believes that they have the correct password --- how can they prove it?
The idea was to do a word-based encode, rather than a byte (or bit) -based one. Computers are good at working with the primitives they have - even letter-based encryption schemes are troublesome because you can easily check: "Am I getting words out of it? Yes? Then I almost certainly have the correct password.". With a word-based encode, one has to actually read the words to see if they make sense.
The idea spread a bit into type-of-word based encoding, as the more we can increase the wetware compute time, the better. So I found a word list with associated word types from "Kevin's Word List Page" (I used the AGID, as it has lots and lots of words and inflections in it). Then I use the password to generate a random number seed, offset the returned word by (now non-random) numbers generated from that seed, and presto.
Update! I've added 2 new items, (1): a special group for the words: "about, after, at, because, by, for, from, in, into, of, on, over, than, to, up, with", so any of those words gets replaced with another random one of those words, and (2): similar groups for the top 100 and top 1000 words (similar, not exact - they remain only replaced by the same type, but if they're (eg) top 100 noun, they'll be replaced by another top 100 noun, etc.
Lots. Including, but not limited to:
Problems with all implementations:
Problems with this implementation: