Self modifying hash encryption algorithm

Question

I am looking for an algorithm to change it's keys every period and can still be deciphered.
Basically I am looking for a way to maintain a secured link between mobile clients and a stationary server in such a way that even if you intercepted the hash or even the authentication credentials themselves they would change on both sides every period.
Does it ring a bell to anyone?
Is there a better way to ensure that even if you will intercept the authentication credentials somehow it will only be valid to a certain request from a certain user?

Answer 1

This is certainly possible -- just for example, the Japanese Purple cipher during the second world war did this. While such a cipher can certainly be difficult, it can also be broken (Purple was).

The reason is fairly simple: your sender and receiver have to generate new keys in synch with each other for the receiver to decipher the messages. That basically means you need something like a secure random number generator to generate new keys. Though that can be difficult to break (with long enough period and such) it's still a pretty normal encryption technique, and depends on having a secure random number generator. Once you have that, however, you're usually not gaining a lot over using the output from the generator more directly (e.g. as the key for a Vernam cipher).

Answer 2

I suggest just using SSL. It is designed to be reasonably resistant to man-in-the-middle attacks, which is what I assume is your concern.

Or maybe Kerberos.

Do not code encryption algorithms yourself.

Answer 3

i'd recommend SSL instead of implementing some encryption algorithm yourself (it WILL be broken if the data you are trying to protect is important enough!). SSL is well tested. with SSL you can use certificates instead of logins/passwords. SSL prevents replay and man in the middle attacks (it uses a handshake at the beginning to make sure a new session key is used for every connection and that both parties are who they claim to be).

another interesting thing that comes to mind is RSA's SecurID. it provides a hardware key that changes every 60 seconds: http://www.rsa.com/node.aspx?id=1156

Answer 4

I guess what you're talking about is finding some way of changing the cryptographic key used in you algorithm periodically, so that even if a key is discovered, then only the data encrypted with that key would be possible to decode? If we avoid worrying about the start-up process, then one way to do it would be to encode part (but not all) of your subsequent keys in the set of data encrypted with one key, and as you switch keys, encrypt a different part of subsequent keys with the new key.

For example, say your keys are 8 elements wide (where an element may be a byte, or a 32-bit word, or whatever), and we'll label the keys you use to encrypt any given block of data as Kn, where 'n' is the block of data encrypted with that key. We'll index elements of the key by saying Kn[0] for the 1st element, up to Kn[7] for the 8th. We'll also call that block of data Dn. Then, the plaintext Dn would include Kn+1[0], Kn+2[1], Kn+3[2], ..., Kn+8[7]. If you were able to decrypt Dn-7 .. Dn, then you'll have fully reconstructed Kn+1, so that you can then decrypt the next data block, and so on. You need to get the plaintext for several blocks in sequence before you can reliably decrypt the rest of the data, though getting the plaintext for any given block will make attacks against the keys of the remainder easier.

Initial setup is a harder problem. SSL would be a good way of distributing K0, K1[1..7], K2[2..7], ..., K7[7].

I'm not a professional cryptographer, so I'm not completely sure how secure this is. This algorithm is offered to you AS IS, without warranty of any kind.