Hiding token information from users

[Tobiah]

I am making QR codes that cell phone users scan in order
to make use of an application. Part of the information
is a token that needs to be passed on to the server, but
I'd rather not allow a person examining the QR code to
be able to see that plain bit of information. I'd like
to scramble up the token so that the result:

1) takes up the same number of characters as the original token

2) Knowing the scheme, I can get the token back from
the scrambled bit

3) The result is alphanumeric.

4) When one character changes in the source,
many characters are likely to change in the
result.

So if my token is:

mytoken2011

The result might be something like:

xm23ffz4uuw

Then
mytoken2012

might yield something very different:

d8ru3jdhvhd

I was thinking of just stringing up all letters and
numbers into a 'wheel' and doing an 18 char rotation on
the chars in the token, but that fails #4. The secret is not like
the key to Fort Knox. We would rather not have the plain
token out there, as it's internal business information,
but we don't have to protect the information at all costs.
Just making it really inconvenient to extract is fine.

Thanks,

Tobiah

[swanny]

On 23/08/2011 8:14 AM, Tobiah wrote:
> I am making QR codes that cell phone users scan in order
> to make use of an application. Part of the information
> is a token that needs to be passed on to the server, but
> I'd rather not allow a person examining the QR code to
> be able to see that plain bit of information. I'd like
> to scramble up the token so that the result:
>
> 1) takes up the same number of characters as the original token
>
> 2) Knowing the scheme, I can get the token back from
> the scrambled bit
>
> 3) The result is alphanumeric.
>
> 4) When one character changes in the source,
> many characters are likely to change in the
> result.
>
> So if my token is:
>
> mytoken2011
>
> The result might be something like:
>
> xm23ffz4uuw
>
> Then
> mytoken2012
>
> might yield something very different:
>
> d8ru3jdhvhd
>
> I was thinking of just stringing up all letters and
> numbers into a 'wheel' and doing an 18 char rotation on
> the chars in the token, but that fails #4. The secret is not like
> the key to Fort Knox. We would rather not have the plain
> token out there, as it's internal business information,
> but we don't have to protect the information at all costs.
> Just making it really inconvenient to extract is fine.
>
> Thanks,
>
> Tobiah

Poly-alphabetic substitution cipher?
Similar to your simple alphabetic substitution cipher, except an
operation on the resulting previous character gives you the offset for
another 'wheel', with jumbled letter order, and so on.

example
in 1 => offset wheel 1, read character out 1
use out 1 to calculate an offset for wheel 2, combine with in 2 (eg add
and modulus) to get out 2.

[Tobiah]

Sorry, I somehow sent this to the wrong group.

>
> Poly-alphabetic substitution cipher?
> Similar to your simple alphabetic substitution cipher, except an
> operation on the resulting previous character gives you the offset for
> another 'wheel', with jumbled letter order, and so on.
>
> example
> in 1 => offset wheel 1, read character out 1
> use out 1 to calculate an offset for wheel 2, combine with in 2 (eg add
> and modulus) to get out 2.
>

My tokens will change each year, as in

token2011, token2012, token2013

You suggestion, it seems would leave me with
encrypted answers that change only by incrementing
the last digit. Not the end of the world, but it
gives insight into the method used.

Tobiah

[swanny]

On 23/08/2011 11:25 PM, Tobiah wrote:
> Sorry, I somehow sent this to the wrong group.
>
>>
>> Poly-alphabetic substitution cipher?
>> Similar to your simple alphabetic substitution cipher, except an
>> operation on the resulting previous character gives you the offset for
>> another 'wheel', with jumbled letter order, and so on.
>>
>> example
>> in 1 => offset wheel 1, read character out 1
>> use out 1 to calculate an offset for wheel 2, combine with in 2 (eg add
>> and modulus) to get out 2.
>>
>
> My tokens will change each year, as in
>
> token2011, token2012, token2013
>
> You suggestion, it seems would leave me with
> encrypted answers that change only by incrementing
> the last digit. Not the end of the world, but it
> gives insight into the method used.
>
> Tobiah
>
You could always base your initial offset on the mod sum of all the
characters and then store the offset as and additional last (or first)
character (for decrypting).
Another suggestion is to make your tokens 16 bytes and AES encrypt them.