Re: a challenge

[Richard Hector <rhector@actrix.gen.nz>]

martin f krafft wrote:
> 
> goal: a 4-16 byte 7-bit character value that somehow encodes the time
>   of creation such that it can be extracted if the encoding scheme/seed
>   is known. the encoded value should be such that it is mostly
>   impossible to change it so as to yield a later time of creation to be
>   encoded. in general, changing the encoded value may well render the
>   data invalid.
> 
>   this is supposed to be a token that's valid for a limited amount of
>   time, after which, a new token has to be fetched. this token should
>   not be obvious (e.g. the timestamp) to prevent people from changing
>   it to be valid longer rather than fetching a new one.

I'm assuming the token is generated by a server and requested by a
client (or that that generalisation is adequate).

>From what you've said, it would appear to be handy for the client to
know when to go get a new token, and not bad that they can read it - you
just don't want the client generating tokens. Have I got that right? If
so, then I would have thought that a public/private key algorithm would
be appropriate. The server generates the token using the private key,
and either the client or the server can check it using the public key.

I haven't investigated the technicalities, though - like whether it's
fast enough, or whether you can get a secure enough token small enough.

HTH,

Richard