I have an idea for a new kind of mobile phone lock screen. When you first create your pattern, you put together a series of colors and compass directions from the following choices: Red, Blue, Yellow, Green, North, South, East, and West. They can be referred to by their first letter. This pattern is the secret I wish to securely store.
Later, when you go to unlock the device the colors overlap the directions and every time you press on the screen you are providing ambiguous information: a color and a direction. After each press, the colors randomize to new locations on the compass. You only mean one piece of information or the other, but it's ambiguous to any Eve that might be observing you. It's also ambiguous to the device itself. The problem I'm trying to solve is how can I compare the series of inputs against the secret and determine if it's a match where the secret is securely (ideally irreversibly) stored?
For example, the pattern might be North, Red, West, Green, and North. I would securely store NRWGN. When the user goes to unlock their screen, they could press a combination similar to North and Red, West and Red, West and Blue, South and Green, and finally North and Yellow. With each press I only need half of the information that's provided and the other half can be ignored. But at the time of input, I can't tell which piece of info is the important half. Hashing every possible combination of colors and directions quickly grows too unwieldy and insecure. At the time of input, I don't even know the length of the secret. If I really need to, I suppose I could store it, but I don't like that.
Here's a functioning jsfiddle prototype, the same one that's on my blog at the link above. It works by keeping a record of the unencrypted pattern and comparing press by press against that pattern. If either piece of information is correct it is accepted and the process moves on. It behaves the way I would like but it does so insecurely.