Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
Not an answer, but some feedback on the possible ergonomics of the idea: I've heard of this sort of idea before (on ATMs, to remap the numeric keypad randomly) to discourage shoulder-surfing. However, it turned out that people hated the idea (because they remembered their pin as a series of keystrokes; they had to look for each digit in succession). I suspect they'll have a similar reaction to your idea. – poncho Sep 10 '15 at 22:28
It's just a concept I'd like to see to completion. I doubt it'll be the norm but maybe it'll be appealing to those looking for an extra layer of security Regardless if anybody likes it, the APIs don't exist for me to make this 100% real. – Corey Ogburn Sep 11 '15 at 0:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.