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
