About

General Overview

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?

Method

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.

Issues

Lots. Including, but not limited to:

Problems with all implementations:

Problems with this implementation:



Back to PoC
Page generated in 0 seconds.